核心子域

Core subdomains

核心子域是公司的工作与其竞争对手不同。这可能涉及发明新产品或服务或通过优化现有流程来降低成本。

A core subdomain is what a company does differently from its competitors. This may involve inventing new products or services or reducing costs by optimizing existing processes.

让我们以优步为例。最初，该公司提供了一种新颖的交通方式：拼车。随着竞争对手的追赶，优步找到了优化和发展其核心业务的方法：例如，通过匹配前往同一方向的乘客来降低成本。

Let’s take Uber as an example. Initially, the company provided a novel form of transportation: ridesharing. As its competitors caught up, Uber found ways to optimize and evolve its core business: for example, reducing costs by matching riders heading in the same direction.

Uber 的核心子域影响其利润。这就是该公司区别于竞争对手的方式。这是公司为客户提供更好服务和/或最大化盈利能力的战略。为了保持竞争优势，核心子领域涉及发明、智能优化、商业知识或其他知识产权。

Uber’s core subdomains affect its bottom line. This is how the company differentiates itself from its competitors. This is the company’s strategy for providing better service to its customers and/or maximizing its profitability. To maintain a competitive advantage, core subdomains involve inventions, smart optimizations, business know-how, or other intellectual property.

考虑另一个例子：谷歌搜索的排名算法。在撰写本文时，谷歌的广告平台占其利润的大部分。也就是说，Google Ads 不是一个子域，而是一个单独的业务域，子域包含它，包括其云计算服务（Google Cloud Platform）、生产力和协作工具（Google Workspaces）以及 Google 母公司 Alphabet 涉足的其他领域公司, 经营. 但是谷歌搜索及其排名算法呢？虽然搜索引擎不是付费服务，但它是 Google Ads 最大的展示平台。它提供出色搜索结果的能力是推动流量的动力，因此，它是广告平台的重要组成部分。由于算法中的错误或竞争对手提供更好的搜索服务而提供次优搜索结果将损害广告业务的收入。所以，对于谷歌来说，排名算法是一个核心子域。

Consider another example: Google Search’s ranking algorithm. At the time of this writing, Google’s advertising platform accounts for the majority of its profits. That said, Google Ads is not a subdomain, but rather a separate business domain with subdomains comprising it, among its cloud computing service (Google Cloud Platform), productivity and collaboration tools (Google Workspaces), and other fields in which Alphabet, Google’s parent company, operates. But what about Google Search and its ranking algorithm? Although the search engine is not a paid service, it serves as the largest display platform for Google Ads. Its ability to provide excellent search results is what drives traffic, and subsequently, it is an important component of the Ads platform. Serving suboptimal search results due to a bug in the algorithm or a competitor coming up with an even better search service will hurt the ad business’s revenue. So, for Google, the ranking algorithm is a core subdomain.

通用子域

Generic subdomains

通用子域是业务活动所有公司都以同样的方式运作。与核心子域一样，通用子域通常很复杂且难以实现。但是，通用子域不会为公司提供任何竞争优势。这里不需要创新或优化：经过实战检验的实施广泛可用，所有公司都在使用它们。

Generic subdomains are business activities that all companies are performing in the same way. Like core subdomains, generic subdomains are generally complex and hard to implement. However, generic subdomains do not provide any competitive edge for the company. There is no need for innovation or optimization here: battle-tested implementations are widely available, and all companies use them.

例如，大多数系统需要对其用户进行身份验证和授权。与其发明专有的身份验证机制，不如使用现有的解决方案更有意义。这样的解决方案可能更可靠、更安全，因为它已经被许多其他有相同需求的公司测试过。

For example, most systems need to authenticate and authorize their users. Instead of inventing a proprietary authentication mechanism, it makes more sense to use an existing solution. Such a solution is likely to be more reliable and secure since it has already been tested by many other companies that have the same needs.

回到珠宝制造商在线销售产品的示例，珠宝设计是一个核心子域，而在线商店是一个通用子域。与其竞争对手使用相同的在线零售平台——相同的通用解决方案——不会影响珠宝制造商的竞争优势。

Going back to the example of a jewelry maker selling its products online, jewelry design is a core subdomain, but the online shop is a generic subdomain. Using the same online retail platform—the same generic solution—as its competitors would not impact the jewelry maker’s competitive advantage.

支持子域

Supporting subdomains

顾名思义，支持子域支持公司的业务。然而，与核心子域相反，支持子域不提供任何竞争优势。

As the name suggests, supporting subdomains support the company’s business. However, contrary to core subdomains, supporting subdomains do not provide any competitive advantage.

例如，考虑一家在线广告公司，其核心子领域包括将广告与访问者匹配、优化广告效果以及最小化广告空间成本。然而，要在这些领域取得成功，公司需要对其创意材料进行分类。公司存储和索引其物理创意材料（例如横幅和登录页面）的方式不会影响其利润。在那个领域没有什么可以发明或优化的。另一方面，创意目录对于实施公司的广告管理和服务系统至关重要。这使得内容编目解决方案成为公司的支持子域之一。

For example, consider an online advertising company whose core subdomains include matching ads to visitors, optimizing the ads’ effectiveness, and minimizing the cost of ad space. However, to achieve success in these areas, the company needs to catalog its creative materials. The way the company stores and indexes its physical creative materials, such as banners and landing pages, does not impact its profits. There is nothing to invent or optimize in that area. On the other hand, the creative catalog is essential for implementing the company’s advertising management and serving systems. That makes the content cataloging solution one of the company’s supporting subdomains.

支持子域的显着特征是解决方案业务逻辑的复杂性。支持子域很简单。他们的业务逻辑主要类似于数据输入屏幕和 ETL（提取、转换、加载）操作；即所谓的 CRUD（创建、读取、更新和删除）接口。这些活动领域不会为公司提供任何竞争优势，因此不需要很高的进入壁垒。

The distinctive characteristic of supporting subdomains is the complexity of the solution’s business logic. Supporting subdomains are simple. Their business logic resembles mostly data entry screens and ETL (extract, transform, load) operations; that is, the so-called CRUD (create, read, update, and delete) interfaces. These activity areas do not provide any competitive advantage for the company, and therefore do not require high entry barriers.

竞争优势

Competitive advantage

只有核心子域才能为公司提供竞争优势。核心子域是公司将自己与竞争对手区分开来的战略。

Only core subdomains provide a competitive advantage to a company. Core subdomains are the company’s strategy for differentiating itself from its competitors.

根据定义，通用子域不能成为任何竞争优势。这些是通用解决方案——公司及其竞争对手使用的相同解决方案。

Generic subdomains, by definition, cannot be a source for any competitive advantage. These are generic solutions—the same solutions used by the company and its competitors.

支持子域进入门槛低，不能提供竞争优势。通常，一家公司不会介意其竞争对手复制其支持的子域——这不会影响其在行业中的竞争力。相反，从战略上讲，公司更希望其支持的子域是通用的、现成的解决方案，从而消除了设计和构建其实现的需要。您将在第 11 章中详细了解支持子域变成通用子域的情况，以及其他可能的排列。附录 A中将概述此类场景的真实案例研究。

Supporting subdomains have low entry barriers and cannot provide a competitive advantage either. Usually, a company wouldn’t mind its competitors copying its supporting subdomains—this won’t affect its competitiveness in the industry. On the contrary, strategically the company would prefer its supporting subdomains to be generic, ready-made solutions, thus eliminating the need to design and build their implementation. You will learn in detail about such cases of supporting subdomains turning into generic subdomains, as well as other possible permutations, in Chapter 11. A real-life case study of such a scenario will be outlined in Appendix A.

公司能够解决的问题越复杂，它能提供的商业价值就越大。复杂的问题不仅限于向消费者提供服务。例如，一个复杂的问题可以使业务更加优化和高效。例如，以较低的运营成本提供与竞争对手相同水平的服务也是一种竞争优势。

The more complex the problems a company is able to tackle, the more business value it can provide. The complex problems are not limited to delivering services to consumers. A complex problem can be, for example, making the business more optimized and efficient. For example, providing the same level of service as competitors do, but at lower operational costs, is a competitive advantage as well.

复杂

Complexity

从更技术的角度来看，重要的是要识别组织的子域，因为不同类型的子域具有不同的复杂程度。在设计软件时，我们必须选择适应业务需求复杂性的工具和技术。因此，识别子域对于设计完善的软件解决方案至关重要。

From a more technical perspective, it’s important to identify the organization’s subdomains, because the different types of subdomains have different levels of complexity. When designing software, we have to choose tools and techniques that accommodate the complexity of the business requirements. Therefore, identifying subdomains is essential for designing a sound software solution.

支持子域的业务逻辑很简单。这些都是基本的ETL操作和CRUD接口，业务逻辑一目了然。通常，它不会超出验证输入或将数据从一种结构转换为另一种结构的范围。

Supporting subdomains’ business logic is simple. These are basic ETL operations and CRUD interfaces, and the business logic is obvious. Often, it doesn’t go beyond validating inputs or converting data from one structure to another.

通用子域要复杂得多。其他人已经投入时间和精力来解决这些问题应该有充分的理由。这些解决方案既不简单也不琐碎。例如，考虑加密算法或身份验证机制。

Generic subdomains are much more complicated. There should be a good reason why others have already invested time and effort in solving these problems. These solutions are neither simple nor trivial. Consider, for example, encryption algorithms or authentication mechanisms.

从知识可用性的角度来看，通用子域是“已知的未知数”。这些是你知道你不知道的事情。此外，这种知识很容易获得。您可以使用行业公认的最佳实践，也可以在需要时聘请专门从事该领域的顾问来帮助设计定制解决方案。

From a knowledge availability perspective, generic subdomains are “known unknowns.” These are the things that you know you don’t know. Furthermore, this knowledge is readily available. You can either use industry-accepted best practices or, if needed, hire a consultant specializing in the area to help design a custom solution.

核心子域很复杂。他们应该努力竞争对手尽可能复制——公司的盈利能力取决于此。这就是为什么在战略上，公司正在寻求解决复杂问题作为他们的核心子领域。

Core subdomains are complex. They should be as hard for competitors to copy as possible—the company’s profitability depends on it. That’s why strategically, companies are looking to solve complex problems as their core subdomains.

有时可能很难区分核心子域和支持子域。复杂性是一个有用的指导原则。询问有问题的子域是否可以变成副业。有人会自己付钱吗？如果是这样，这是一个核心子域。类似的推理适用于区分支​​持子域和通用子域：破解您自己的实现比集成外部实现更简单、成本更低吗？如果是这样，这是一个支持子域。

At times it may be challenging to differentiate between core and supporting subdomains. Complexity is a useful guiding principle. Ask whether the subdomain in question can be turned into a side business. Would someone pay for it on its own? If so, this is a core subdomain. Similar reasoning applies for differentiating supporting and generic subdomains: would it be simpler and cheaper to hack your own implementation, rather than integrating an external one? If so, this is a supporting subdomain.

从更技术的角度来看，确定核心子域很重要其复杂性将影响软件设计。正如我们之前讨论的，核心子域不一定与软件相关。识别与软件相关的核心子域的另一个有用的指导原则是评估您必须在代码中建模和实现的业务逻辑的复杂性。业务逻辑是否类似于用于数据输入的 CRUD 接口，或者您是否必须实施复杂的算法或由复杂的业务规则和不变量编排的业务流程？前者是辅助子域的标志，后者是典型的核心子域。

From a more technical perspective, it’s important to identify the core subdomains whose complexity will affect software design. As we discussed earlier, a core subdomain is not necessarily related to software. Another useful guiding principle for identifying software-related core subdomains is to evaluate the complexity of the business logic that you will have to model and implement in code. Does the business logic resemble CRUD interfaces for data entry, or do you have to implement complex algorithms or business processes orchestrated by complex business rules and invariants? In the former case, it’s a sign of a supporting subdomain, while the latter is a typical core subdomain.

图 1-1中的图表表示三种类型的子域在业务差异化和业务逻辑复杂性方面的相互作用。支持子域和通用子域之间的交集是一个灰色区域：它可以走任何一条路。如果存在支持子域功能的通用解决方案，则生成的子域类型取决于集成通用解决方案是否比从头实现功能更简单和/或更便宜。

The chart in Figure 1-1 represents the interplay between the three types of subdomains in terms of business differentiation and business logic complexity. The intersection between the supporting and generic subdomains is a gray area: it can go either way. If a generic solution exists for a supporting subdomain’s functionality, the resultant subdomain type depends on whether it’s simpler and/or cheaper to integrate the generic solution than it is to implement the functionality from scratch.

图 1-1。三类子域的业务差异化和业务逻辑复杂度

挥发性

Volatility

如前所述，核心子域可以经常更改。如果一个问题可以在第一次尝试中解决，这可能不是一个好的竞争优势——竞争对手会很快赶上来。因此，核心子域的解决方案应运而生。必须尝试、改进和优化不同的实现。此外，核心子域的工作从未完成。公司不断创新和发展核心子领域。这些更改以添加新功能或优化现有功能的形式出现。无论哪种方式，其核心子域的不断发展对于公司保持领先于竞争对手至关重要。

As mentioned previously, core subdomains can change often. If a problem can be solved on the first attempt, it’s probably not a good competitive advantage—competitors will catch up fast. Consequently, solutions for core subdomains are emergent. Different implementations have to be tried out, refined, and optimized. Moreover, the work on core subdomains is never done. Companies continuously innovate and evolve core subdomains. The changes come in the form of adding new features or optimizing existing functionality. Either way, the constant evolution of its core subdomains is essential for a company to stay ahead of its competitors.

与核心子域相反，支持子域不经常更改。它们不会为公司提供任何竞争优势，因此与在核心子域中投入的相同努力相比，支持子域的发展提供的商业价值微乎其微。

Contrary to the core subdomains, supporting subdomains do not change often. They do not provide any competitive advantage for the company, and therefore the evolution of a supporting subdomain provides a minuscule business value compared to the same effort invested in a core subdomain.

尽管有现有的解决方案，但通用子域会随着时间而改变。这些更改可以以安全补丁、错误修复或针对一般问题的全新解决方案的形式出现。

Despite having existing solutions, generic subdomains can change over time. The changes can come in the form of security patches, bug fixes, or entirely new solutions to the generic problems.

解决策略

Solution strategy

核心子域为公司提供了竞争能力与业内其他参与者。这是一项关键业务责任，但这是否意味着支持和通用子域不重要？当然不是。公司需要所有子域才能在其业务域中工作。子域就像基础构建块：拿走一个，整个结构可能会倒塌。也就是说，我们可以利用不同类型子域的固有属性来选择实现策略，以最有效的方式实现每种类型的子域。

Core subdomains provide the company its ability to compete with other players in the industry. That’s a business-critical responsibility, but does it mean that supporting and generic subdomains are not important? Of course not. All subdomains are required for the company to work in its business domain. The subdomains are like foundational building blocks: take one away and the whole structure may fall down. That said, we can leverage the inherent properties of the different types of subdomains to choose implementation strategies to implement each type of subdomain in the most efficient manner.

核心子域必须在内部实施。它们不能被购买或领养；这会破坏竞争优势的概念，因为公司的竞争对手也可以这样做。

Core subdomains have to be implemented in-house. They cannot be bought or adopted; that would undermine the notion of competitive advantage, as the company’s competitors would be able to do the same.

将核心子域的实施外包也是不明智的。这是一项战略投资。在核心子域上偷工减料不仅在短期内有风险，而且从长远来看可能会产生致命的后果：例如，无法支持公司目标的无法维护的代码库。组织最熟练的人才应该被分配到其核心子领域工作。此外，在内部实施核心子域使公司能够更快地进行更改和改进解决方案，从而在更短的时间内建立竞争优势。

It would also be unwise to outsource the implementation of a core subdomain. It is a strategic investment. Cutting corners on a core subdomain is not only risky in the short term but can have fatal consequences in the long run: for example, unmaintainable codebases that cannot support the company’s goals and objectives. The organization’s most skilled talent should be assigned to work on its core subdomains. Furthermore, implementing core subdomains in-house allows the company to make changes and evolve the solution more quickly, and therefore build the competitive advantage in less time.

由于核心子域的要求是预计会经常和持续地改变，解决方案必须是可维护和易于发展的。因此，核心子域需要实施最先进的工程技术。

Since core subdomains’ requirements are expected to change often and continuously, the solution must be maintainable and easy to evolve. Thus, core subdomains require implementation of the most advanced engineering techniques.

由于通用子域很难但已经解决了问题，购买现成的产品或采用开源解决方案比投入时间和精力在内部实施通用子域更具成本效益。

Since generic subdomains are hard but already solved problems, it’s more cost-effective to buy an off-the-shelf product or adopt an open source solution than invest time and effort into implementing a generic subdomain in-house.

缺乏竞争优势使得避免实施是合理的内部支持子域。但是，与通用子域不同，没有现成的解决方案可用。因此，公司别无选择，只能自己实施支持子域。也就是说，业务逻辑的简单性和更改的不频繁性使得偷工减料变得容易。

Lack of competitive advantage makes it reasonable to avoid implementing supporting subdomains in-house. However, unlike generic subdomains, no ready-made solutions are available. So, a company has no choice but to implement supporting subdomains itself. That said, the simplicity of the business logic and infrequency of changes make it easy to cut corners.

支持子域不需要复杂的设计模式或其他高级工程技术。一个快速的应用程序开发框架将足以实现业务逻辑，而不会引入意外的复杂性。

Supporting subdomains do not require elaborate design patterns or other advanced engineering techniques. A rapid application development framework will suffice to implement the business logic without introducing accidental complexities.

从人员配置的角度来看，支持子域不需要高技能的技术能力，并且提供了培养有前途的人才的绝佳机会。保留团队中在应对核心子域的复杂挑战方面经验丰富的工程师。最后，业务逻辑的简单性使得支持子域成为外包的良好候选者。

From a staffing perspective, supporting subdomains do not require highly skilled technical aptitude and provide a great opportunity to train up-and-coming talent. Save the engineers on your team who are experienced in tackling complex challenges for the core subdomains. Finally, the simplicity of the business logic makes supporting subdomains a good candidate for outsourcing.

表 1-1总结了三种子域的不同之处。

Table 1-1 summarizes the aspects in which the three types of subdomains differ.

提取子域

Distilling subdomains

粗粒度的子域是一个很好的起点，但细节决定成败。我们必须确保我们不会遗漏隐藏在错综复杂的业务功能中的重要信息。

Coarse-grained subdomains are a good starting point, but the devil is in the details. We have to make sure we are not missing important information hidden in the intricacies of the business function.

让我们回到客户服务部门的例子。如果我们调查它的内部运作，我们会发现一个典型的客户服务部门是由更细粒度的组件组成的，例如服务台系统、轮班管理和调度、电话系统等。当被视为单独的子域时，这些活动可以有不同的类型：虽然帮助台和电话系统是通用子域，但轮班管理是辅助子域，而公司可能会开发其巧妙的算法来将事件路由给在类似案例中取得成功的代理过去。路由算法需要分析传入的案例并识别过去经验中的相似之处——这两者都是重要的任务。由于路由算法允许公司提供比竞争对手更好的客户体验，路由算法是一个核心子域。这个例子在图 1-2。

Let’s go back to the example of the customer service department. If we investigate its inner workings, we will see that a typical customer service department is composed of finer-grained components, such as a help desk system, shift management and scheduling, telephone system, and so on. When viewed as individual subdomains, these activities can be of different types: while help desk and telephone systems are generic subdomains, shift management is a supporting one, while a company may develop its ingenious algorithm for routing incidents to agents having success with similar cases in the past. The routing algorithm requires analyzing incoming cases and identifying similarities in past experience—both of which are nontrivial tasks. Since the routing algorithm allows the company to provide a better customer experience than its competitors, the routing algorithm is a core subdomain. This example is demonstrated in Figure 1-2.

图 1-2。分析疑似通用子域的内部工作原理，以找到更细粒度的核心子域、支持子域和两个通用子域

另一方面，我们不能无限地向下钻取，在越来越低的粒度级别寻找洞察力。你应该什么时候停止？

On the other hand, we cannot drill down indefinitely, looking for insights at lower and lower levels of granularity. When should you stop?

子域作为连贯的用例

Subdomains as coherent use cases

从技术角度来看，子域类似于一组相互关联、连贯的用例。这样的用例集通常涉及相同的参与者、业务实体，并且它们都操作一组密切相关的数据。

From a technical perspective, subdomains resemble sets of interrelated, coherent use cases. Such sets of use cases usually involve the same actor, the business entities, and they all manipulate a closely related set of data.

考虑图 1-3中所示的信用卡支付网关的用例图。用例与他们正在使用的数据和涉及的参与者紧密相关。因此，所有用例都构成了信用卡支付子域。

Consider the use case diagram for a credit card payment gateway shown in Figure 1-3. The use cases are tightly bound by the data they are working with and the involved actors. Hence, all of the use cases form the credit card payment subdomain.

我们可以使用“子域作为一组连贯的用例”的定义作为何时停止寻找更细粒度子域的指导原则。这些是子域最精确的边界。

We can use the definition of “subdomains as a set of coherent use cases” as a guiding principle for when to stop looking for finer-grained subdomains. These are the most precise boundaries of the subdomains.

图 1-3。信用卡支付子域的用例图

您是否应该始终努力识别这种激光聚焦的子域边界？这对于核心子域来说绝对是必要的。核心子域是最重要的、易变的和复杂的。我们必须尽可能多地提炼它们，因为这将使我们能够提取所有通用和支持功能，并将精力投入到更有针对性的功能上。

Should you always strive to identify such laser-focused subdomain boundaries? It is definitely necessary for core subdomains. Core subdomains are the most important, volatile, and complex. It’s essential that we distill them as much as possible since that will allow us to extract all generic and supporting functionalities and invest the effort on a much more focused functionality.

对于支持和通用子域，蒸馏可以稍微放松。如果进一步深入研究没有揭示任何可以帮助您做出软件设计决策的新见解，那么它可能是一个停下来的好地方。例如，当所有更细粒度的子域都与原始子域属于同一类型时，就会发生这种情况。

The distillation can be somewhat relaxed for supporting and generic subdomains. If drilling down further doesn’t unveil any new insights that can help you make software design decisions, it can be a good place to stop. This can happen, for example, when all of the finer-grained subdomains are of the same type as the original subdomain.

考虑图 1-4中的示例。帮助台系统子域的进一步提炼用处不大，因为它不会透露任何战略信息，并且将使用粗粒度的现成工具作为解决方案。

Consider the example in Figure 1-4. Further distillation of the help desk system subdomain is less useful, as it doesn’t reveal any strategic information, and a coarse-grained, off-the-shelf tool will be used as the solution.

图 1-4。提取帮助台系统子域，揭示通用内部组件

识别子域时要考虑的另一个重要问题是我们是否需要所有子域。

Another important question to consider when identifying the subdomains is whether we need all of them.

专注于要点

Focus on the essentials

子域是一种减轻制作过程的工具软件设计决策。所有组织都可能有相当多的业务功能来推动他们的竞争优势，但与软件无关。我们在本章前面讨论的珠宝制造商只是一个例子。

Subdomains are a tool that alleviates the process of making software design decisions. All organizations likely have quite a few business functionalities that drive their competitive advantage but have nothing to do with software. The jewelry maker we discussed earlier in this chapter is but one example.

在寻找子域时，重要的是识别与软件无关的业务功能，承认它们，并关注与您正在处理的软件系统相关的业务方面。

When looking for subdomains, it’s important to identify business functions that are not related to software, acknowledge them as such, and focus on aspects of the business that are relevant to the software system you are working on.

业务域和子域

Business domain and subdomains

Gigmaster的业务领域是门票销售。这就是它为客户提供的服务。

Gigmaster’s business domain is ticket sales. That’s the service it provides to its customers.

设计决策

Design decisions

了解起作用的子域及其类型之间的差异，我们已经可以做出几个战略设计决策：

Knowing the subdomains at play and the differences between their types, we can already make several strategic design decisions:

• 推荐引擎、数据匿名化和移动应用程序必须使用最先进的工程工具和技术在内部实施。这些模块将最常更改。

• The recommendation engine, data anonymization, and mobile app have to be implemented in-house using the most advanced engineering tools and techniques. These modules are going to change the most often.

• 应使用现成或开源解决方案进行数据加密、计费、清算和身份验证。

• Off-the-shelf or open source solutions should be used for data encryption, accounting, clearing, and authentication.

• 与流媒体服务和社交网络的集成，以及参与演出的模块，都可以外包。

• Integration with streaming services and social networks, as well as the module for attended gigs, can be outsourced.

业务域和子域

Business domain and subdomains

BusVNext 为其客户提供优化的巴士乘坐服务。业务领域为公共交通。

BusVNext provides optimized bus rides to its customers. The business domain is public transportation.

设计决策

Design decisions

了解起作用的子域及其类型之间的差异，我们已经可以做出一些战略设计决策：

Knowing the subdomains at play and the differences between their types, we can already make a number of strategic design decisions:

• 路由算法、数据分析、车队管理和应用程序可用性必须使用最精细的技术工具和模式在内部实施。

• The routing algorithm, data analysis, fleet management, and app usability have to be implemented in-house using the most elaborate technical tools and patterns.

• 促销管理模块的实施可以外包。

• Implementation of the promotions management module can be outsourced.

• 识别交通状况、授权用户以及管理财务记录和交易可以卸载到外部服务提供商。

• Identifying traffic conditions, authorizing users, and managing financial records and transactions can be offloaded to external service providers.

模棱两可的条款

Ambiguous terms

假设在某些业务领域中，保单一词具有多种含义：它可以表示监管规则或保险合同。确切的含义可以在人与人的互动中得出，具体取决于上下文。然而，软件并不能很好地处理歧义，而且在代码中对“策略”实体进行建模可能会很麻烦且具有挑战性。

Let’s say that in some business domain, the term policy has multiple meanings: it can mean a regulatory rule or an insurance contract. The exact meaning can be worked out in human-to-human interaction, depending on the context. Software, however, doesn’t cope well with ambiguity, and it can be cumbersome and challenging to model the “policy” entity in code.

通用语言要求每个术语都有单一含义，因此“政策”应该使用监管规则和保险合同这两个术语明确建模。

Ubiquitous language demands a single meaning for each term, so “policy” should be modeled explicitly using the two terms regulatory rule and insurance contract.

同义词

Synonymous terms

在通用语言中，两个术语不能互换使用。例如，许多系统使用术语user。然而，仔细检查领域专家的行话可能会发现用户和其他术语可以互换使用：例如，用户、访问者、管理员、帐户等。

Two terms cannot be used interchangeably in a ubiquitous language. For example, many systems use the term user. However, a careful examination of the domain experts’ lingo may reveal that user and other terms are used interchangeably: for example, user, visitor, administrator, account, etc.

同义词乍一看似乎无害。但是，在大多数情况下，它们表示不同的概念。在此示例中，访问者和帐户在技术上都是指系统的用户；然而，在大多数系统中，未注册和注册用户代表不同的角色并具有不同的行为。例如，“访问者”数据主要用于分析目的，而“账户”实际上使用系统及其功能。

Synonymous terms can seem harmless at first. However, in most cases, they denote different concepts. In this example, both visitor and account technically refer to the system’s users; however, in most systems, unregistered and registered users represent different roles and have different behaviors. For example, the “visitors” data is used mainly for analysis purposes, whereas “accounts” actually uses the system and its functionality.

最好在其特定上下文中明确使用每个术语。了解使用术语之间的差异可以构建更简单、更清晰的模型和业务领域实体的实现。

It is preferable to use each term explicitly in its specific context. Understanding the differences between the terms in use allows for building simpler and clearer models and implementations of the business domain’s entities.

共享范围

Shared scope

重叠模型耦合参与的生命周期有界上下文。对共享模型所做的更改会立即影响所有限界上下文。因此，为了最小化变化的级联效应，应该限制重叠模型，只暴露模型中必须由两个有界上下文实现的那部分。理想情况下，共享内核将仅包含旨在跨越有界上下文边界传递的集成契约和数据结构。

The overlapping model couples the lifecycles of the participating bounded contexts. A change made to the shared model has an immediate effect on all the bounded contexts. Hence, to minimize the cascading effects of changes, the overlapping model should be limited, exposing only that part of the model that has to be implemented by both bounded contexts. Ideally, the shared kernel will consist only of integration contracts and data structures that are intended to be passed across the bounded contexts’ boundaries.

执行

Implementation

共享内核的实现使得对其源代码的任何修改都会立即反映在使用它的所有限界上下文中。

The shared kernel is implemented so that any modification to its source code is immediately reflected in all the bounded contexts using it.

如果组织使用单一存储库方法，则这些可以是多个限界上下文引用的相同源文件。如果无法使用共享存储库，则可以将共享内核提取到专用项目中，并在有界上下文中作为链接库进行引用。无论哪种方式，对共享内核的每次更改都必须触发对所有受影响的限界上下文的集成测试。

If the organization uses the mono-repository approach, these can be the same source files referenced by multiple bounded contexts. If using a shared repository is not possible, the shared kernel can be extracted into a dedicated project and referenced in the bounded contexts as a linked library. Either way, each change to the shared kernel must trigger integration tests for all the affected bounded contexts.

由于共享内核属于多个限界上下文，因此需要持续集成更改。不将共享内核更改传播到所有相关的有界上下文会导致模型不一致：有界上下文可能依赖于共享内核的陈旧实现，从而导致数据损坏和/或运行时问题。

The continuous integration of changes is required because the shared kernel belongs to multiple bounded contexts. Not propagating shared kernel changes to all related bounded contexts leads to inconsistencies in a model: bounded contexts may rely on stale implementations of the shared kernel, leading to data corruption and/or runtime issues.

何时使用共享内核

When to use shared kernel

共享内核模式的总体适用性标准是重复成本与协调成本之比。由于该模式在参与的限界上下文之间引入了强依赖性，因此只有当复制成本高于协调成本时才应应用它——换句话说，只有当需要集成两个限界上下文应用于共享模型的更改时比协调共享代码库中的更改需要更多的努力。

The overarching applicability criterion for the shared kernel pattern is the cost of duplication versus the cost of coordination. Since the pattern introduces a strong dependency between the participating bounded contexts, it should be applied only when the cost of duplication is higher than the cost of coordination—in other words, only when integrating changes applied to the shared model by both bounded contexts will require more effort than coordinating the changes in the shared codebase.

集成成本和复制成本之间的差异取决于模型的波动性。它更改得越频繁，集成成本就越高。因此，共享内核自然会应用于变化最大的子域：核心子域。

The difference between the integration and duplication costs depends on the volatility of the model. The more frequently it changes, the higher the integration costs will be. Therefore, the shared kernel will naturally be applied for the subdomains that change the most: the core subdomains.

从某种意义上说，共享内核模式与上一章介绍的限界上下文原则相矛盾。如果参与的限界上下文不是由同一个团队实现的，则引入共享内核与单个团队应拥有限界上下文的原则相矛盾。重叠模型——共享内核——实际上是由多个团队开发的。

In a sense, the shared kernel pattern contradicts the principles of bounded contexts introduced in the previous chapter. If the participating bounded contexts are not implemented by the same team, introducing a shared kernel contradicts the principle that a single team should own a bounded context. The overlapping model—the shared kernel—is, in effect, being developed by multiple teams.

这就是必须证明使用共享内核的原因。这是一个实用的例外，应该仔细考虑。实现共享内核的一个常见用例是当通信或协作问题阻止实现伙伴关系模式时——例如，由于地理限制或组织政治。在没有适当协调的情况下实施密切相关的功能将导致集成问题、模型不同步以及关于哪个模型设计更好的争论。最小化共享内核的范围控制级联更改的范围，并且为每个更改触发集成测试是一种强制早期检测集成问题的方法。

That’s the reason why the use of a shared kernel has to be justified. It’s a pragmatic exception that should be considered carefully. A common use case for implementing a shared kernel is when communication or collaboration issues prevent implementing the partnership pattern—for example, because of geographical constraints or organizational politics. Implementing a closely related functionality without proper coordination will result in integration issues, desynchronized models, and arguments about which model is better designed. Minimizing the shared kernel’s scope controls the scope of cascading changes, and triggering integration tests for each change is a way to enforce early detection of integration issues.

应用共享内核模式的另一个常见用例（尽管是临时的）是遗留系统的逐步现代化。在这种情况下，共享代码库可以作为一种务实的中间解决方案，用于逐渐将系统分解为有界上下文。

Another common use case for applying the shared kernel pattern, albeit a temporary one, is the gradual modernization of a legacy system. In such a scenario, the shared codebase can be a pragmatic intermediate solution for gradually decomposing the system into bounded contexts.

最后，共享内核非常适合集成由同一团队拥有和实现的限界上下文。在这种情况下，有界上下文的临时集成（伙伴关系）可以随着时间的推移“清除”上下文的边界。共享内核可用于显式定义限界上下文的集成契约。

Finally, a shared kernel can be a good fit for integrating bounded contexts owned and implemented by the same team. In such a case, an ad hoc integration of the bounded contexts—a partnership—can “wash out” the contexts’ boundaries over time. A shared kernel can be used for explicitly defining the bounded contexts’ integration contracts.

缺乏交易行为

Lack of transactional behavior

未能实现事务行为的一个简单示例是在没有总体事务的情况下发布多个更新。考虑以下更新 Users 表中的记录并将记录插入到 VisitsLog 表中的方法：

A trivial example of failing to implement transactional behavior is to issue multiple updates without an overarching transaction. Consider the following method that updates a record in the Users table and inserts a record into the VisitsLog table:

01  public class LogVisit
02  {
03      ...
04
05      public void Execute(Guid userId, DataTime visitedOn)
06      {
07          _db.Execute("UPDATE Users SET last_visit=@p1 WHERE user_id=@p2",
08              visitedOn, userId);
09          _db.Execute(@"INSERT INTO VisitsLog(user_id, visit_date)
10                       VALUES(@p1, @p2)", userId, visitedOn);
11      }
12  }

01  public class LogVisit
02  {
03      ...
04
05      public void Execute(Guid userId, DataTime visitedOn)
06      {
07          _db.Execute("UPDATE Users SET last_visit=@p1 WHERE user_id=@p2",
08              visitedOn, userId);
09          _db.Execute(@"INSERT INTO VisitsLog(user_id, visit_date)
10                       VALUES(@p1, @p2)", userId, visitedOn);
11      }
12  }

如果在更新 Users 表中的记录（第 7 行）但在第 9 行附加日志记录成功之前出现任何问题，系统将最终处于不一致状态。Users 表将被更新，但不会将相应的记录写入 VisitsLog 表。问题可能是由于网络中断、数据库超时或死锁，甚至是执行该进程的服务器崩溃引起的。

If any issue occurs after the record in the Users table was updated (line 7) but before appending the log record on line 9 succeeds, the system will end up in an inconsistent state. The Users table will be updated but no corresponding record will be written to the VisitsLog table. The issue can be due to anything from a network outage to a database timeout or deadlock, or even a crash of the server executing the process.

这可以通过引入包含两个数据更改的适当事务来解决：

This can be fixed by introducing a proper transaction encompassing both data changes:

public class LogVisit
{
    ...

    public void Execute(Guid userId, DataTime visitedOn)
    {
        try
        {
            _db.StartTransaction();

            _db.Execute(@"UPDATE Users SET last_visit=@p1
                       WHERE user_id=@p2",
                       visitedOn, userId);

            _db.Execute(@"INSERT INTO VisitsLog(user_id, visit_date)
                       VALUES(@p1, @p2)",
                       userId, visitedOn);

            _db.Commit();
        } catch {
            _db.Rollback();
            throw;
        }
    }
}

public class LogVisit
{
    ...

    public void Execute(Guid userId, DataTime visitedOn)
    {
        try
        {
            _db.StartTransaction();

            _db.Execute(@"UPDATE Users SET last_visit=@p1
                       WHERE user_id=@p2",
                       visitedOn, userId);

            _db.Execute(@"INSERT INTO VisitsLog(user_id, visit_date)
                       VALUES(@p1, @p2)",
                       userId, visitedOn);

            _db.Commit();
        } catch {
            _db.Rollback();
            throw;
        }
    }
}

由于关系数据库对跨多个记录的事务的本机支持，因此修复很容易实施。当您必须在不支持多记录事务的数据库中发布多个更新时，或者当您使用不可能在分布式事务中统一的多个存储机制时，事情会变得更加复杂。让我们看一个后一种情况的例子。

The fix is easy to implement due to relational databases’ native support of transactions spanning multiple records. Things get more complicated when you have to issue multiple updates in a database that doesn’t support multirecord transactions, or when you are working with multiple storage mechanisms that are impossible to unite in a distributed transaction. Let’s see an example of the latter case.

分布式事务

Distributed transactions

在现代分布式系统中，通常的做法是更改数据库中的数据，然后通过将消息发布到消息总线来将更改通知系统的其他组件。考虑在前面的示例中，我们必须将访问发布到消息总线，而不是在表中记录访问：

In modern distributed systems, it’s a common practice to make changes to the data in a database and then notify other components of the system about the changes by publishing messages into a message bus. Consider that in the previous example, instead of logging a visit in a table, we have to publish it to a message bus:

01  public class LogVisit
02  {
03      ...
04
05      public void Execute(Guid userId, DataTime visitedOn)
06      {
07          _db.Execute("UPDATE Users SET last_visit=@p1 WHERE user_id=@p2",
08                     visitedOn,userId);
09          _messageBus.Publish("VISITS_TOPIC",
10                             new { UserId = userId, VisitDate = visitedOn });
11      }
12  }

01  public class LogVisit
02  {
03      ...
04
05      public void Execute(Guid userId, DataTime visitedOn)
06      {
07          _db.Execute("UPDATE Users SET last_visit=@p1 WHERE user_id=@p2",
08                     visitedOn,userId);
09          _messageBus.Publish("VISITS_TOPIC",
10                             new { UserId = userId, VisitDate = visitedOn });
11      }
12  }

与前面的示例一样，在第 7 行之后但在第 9 行成功之前发生的任何故障都将破坏系统的状态。Users 表将更新，但不会通知其他组件，因为发布到消息总线失败。

As in the previous example, any failure occurring after line 7 but before line 9 succeeds will corrupt the system’s state. The Users table will be updated but the other components won’t be notified as publishing to the message bus has failed.

不幸的是，解决这个问题并不像前面的例子那么容易。跨越多个存储机制的分布式事务复杂、难以扩展、容易出错，因此通常被避免。在第 8 章中，您将学习如何使用 CQRS 架构模式来填充多种存储机制。此外，第 9 章将介绍发件箱模式，它可以在将更改提交到另一个数据库后可靠地发布消息。

Unfortunately, fixing the issue is not as easy as in the previous example. Distributed transactions spanning multiple storage mechanisms are complex, hard to scale, error prone, and therefore are usually avoided. In Chapter 8, you will learn how to use the CQRS architectural pattern to populate multiple storage mechanisms. In addition, Chapter 9 will introduce the outbox pattern, which enables reliable publishing of messages after committing changes to another database.

让我们看一个更复杂的交易行为实施不当的例子。

Let’s see a more intricate example of improper implementation of transactional behavior.

隐式分布式事务

Implicit distributed transactions

考虑以下看似简单的方法：

Consider the following deceptively simple method:

public class LogVisit
{
    ...
 
    public void Execute(Guid userId)
    {
        _db.Execute("UPDATE Users SET visits=visits+1 WHERE user_id=@p1",
                    userId);
    }
}

public class LogVisit
{
    ...
 
    public void Execute(Guid userId)
    {
        _db.Execute("UPDATE Users SET visits=visits+1 WHERE user_id=@p1",
                    userId);
    }
}

此方法不是像前面的示例那样跟踪上次访问日期，而是为每个用户维护一个访问计数器。调用该方法会将相应计数器的值增加 1。该方法所做的只是更新驻留在一个数据库中的一个表中的一个值。然而，这仍然是一个可能导致状态不一致的分布式事务。

Instead of tracking the last visit date as in the previous examples, this method maintains a counter of visits for each user. Calling the method increases the corresponding counter’s value by 1. All the method does is update one value, in one table, residing in one database. Yet this is still a distributed transaction that can potentially lead to inconsistent state.

这个例子构成了一个分布式事务，因为它向数据库和调用该方法的外部进程传递信息，如图5-2所示。

This example constitutes a distributed transaction because it communicates information to the databases and the external process that called the method, as demonstrated in Figure 5-2.

图 5-2。更新数据LogVisit并通知调用者操作成功或失败的操作

尽管该execute方法是 类型的void，即它不返回任何数据，但它仍然传达操作是成功还是失败：如果失败，调用者将得到一个异常。如果方法成功，但将结果传递给调用者失败怎么办？例如：

Although the execute method is of type void, that is, it doesn’t return any data, it still communicates whether the operation has succeeded or failed: if it failed, the caller will get an exception. What if the method succeeds, but the communication of the result to the caller fails? For example:

• 如果LogVisit是 REST 服务的一部分并且出现网络中断；或者

• If LogVisit is part of a REST service and there is a network outage; or

• 如果两者LogVisit和调用者都在同一个进程中运行，但在调用者跟踪操作的成功执行之前进程失败了LogVisit？

• If both LogVisit and the caller are running in the same process, but the process fails before the caller gets to track successful execution of the LogVisit action?

在这两种情况下，消费者都会假设失败并LogVisit再次尝试调用。再次执行该LogVisit逻辑将导致计数器值的错误增加。总的来说，它会增加 2 而不是 1。如前两个示例中，代码未能正确实现事务脚本模式，并无意中导致破坏系统状态。

In both cases, the consumer will assume failure and try calling LogVisit again. Executing the LogVisit logic again will result in an incorrect increase of the counter’s value. Overall, it will be increased by 2 instead of 1. As in the previous two examples, the code fails to implement the transaction script pattern correctly, and inadvertently leads to corrupting the system’s state.

与前面的示例一样，此问题没有简单的修复方法。这完全取决于业务领域及其需求。在此特定示例中，确保事务行为的一种方法是使操作幂等：即，即使操作重复多次，也会导致相同的结果。

As in the previous example, there is no simple fix for this issue. It all depends on the business domain and its needs. In this specific example, one way to ensure transactional behavior is to make the operation idempotent: that is, leading to the same result even if the operation repeated multiple times.

例如，我们可以要求消费者传递计数器的值。要提供计数器的值，调用者必须首先读取当前值，在本地增加它，然后将更新后的值作为参数提供。即使该操作将被执行多次，也不会改变最终结果：

For example, we can ask the consumer to pass the value of the counter. To supply the counter’s value, the caller will have to read the current value first, increase it locally, and then provide the updated value as a parameter. Even if the operation will be executed multiple times, it won’t change the end result:

public class LogVisit
{
    ...
      
    public void Execute(Guid userId, long visits)
    {
        _db.Execute("UPDATE Users SET visits = @p1 WHERE user_id=@p2",
                   visits, userId);
    }
}

public class LogVisit
{
    ...
      
    public void Execute(Guid userId, long visits)
    {
        _db.Execute("UPDATE Users SET visits = @p1 WHERE user_id=@p2",
                   visits, userId);
    }
}

解决此类问题的另一种方法是使用乐观并发控制：在调用操作之前LogVisit，调用者已读取计数器的当前值并将其LogVisit作为参数传递给。LogVisit仅当计数器的值等于调用者最初读取的值时才会更新计数器的值：

Another way to address such an issue is to use optimistic concurrency control: prior to calling the LogVisit operation, the caller has read the counter’s current value and passed it to LogVisit as a parameter. LogVisit will update the counter’s value only if it equals the one initially read by the caller:

public class LogVisit
{
...
  
    public void Execute(Guid userId, long expectedVisits)
      {
        _db.Execute(@"UPDATE Users SET visits=visits+1
                      WHERE user_id=@p1 and visits = @p2",
                      userId, visits);
    }
}

public class LogVisit
{
...
  
    public void Execute(Guid userId, long expectedVisits)
      {
        _db.Execute(@"UPDATE Users SET visits=visits+1
                      WHERE user_id=@p1 and visits = @p2",
                      userId, visits);
    }
}

使用相同输入参数的后续执行LogVisit不会更改数据，因为WHERE...visits = @prm2不会满足条件。

Subsequent executions of LogVisit with the same input parameters won’t change the data, as the WHERE...visits = @prm2 condition won’t be fulfilled.

复杂

Complexity

域的业务逻辑本来就很复杂，所以对象用于建模它不应该引入任何额外的意外复杂性。该模型应该没有任何基础设施或技术问题，例如实现对数据库或系统其他外部组件的调用。此限制要求模型的对象是普通的旧对象，即在不依赖或直接合并任何基础结构组件或框架的情况下实现业务逻辑的对象。^3个

The domain’s business logic is already inherently complex, so the objects used for modeling it should not introduce any additional accidental complexities. The model should be devoid of any infrastructural or technological concerns, such as implementing calls to databases or other external components of the system. This restriction requires the model’s objects to be plain old objects, objects implementing business logic without relying on or directly incorporating any infrastructural components or frameworks.³

无处不在的语言

Ubiquitous language

强调业务逻辑而不是技术问题使得领域模型的对象更容易遵循限界上下文的通用语言的术语。换句话说，这种模式允许代码“说”通用语言并遵循领域专家的心智模型。

The emphasis on business logic instead of technical concerns makes it easier for the domain model’s objects to follow the terminology of the bounded context’s ubiquitous language. In other words, this pattern allows the code to “speak” the ubiquitous language and to follow the domain experts’ mental models.

值对象

Value object

值对象是可以通过其值的组合来标识的对象。例如，考虑一个颜色对象：

A value object is an object that can be identified by the composition of its values. For example, consider a color object:

class Color
{
    int _red;
    int _green;
    int _blue;
}

class Color
{
    int _red;
    int _green;
    int _blue;
}

红色、绿色和蓝色三个字段的值的组合定义了一种颜色。更改其中一个字段的值将产生新的颜色。没有两种颜色可以具有相同的值。此外，相同颜色的两个实例必须具有相同的值。因此，不需要明确的识别字段来识别颜色。

The composition of the values of the three fields red, green, and blue defines a color. Changing the value of one of the fields will result in a new color. No two colors can have the same values. Also, two instances of the same color must have the same values. Therefore, no explicit identification field is needed to identify colors.

图 6-1ColorId中显示的字段不仅是多余的，而且实际上为错误创造了机会。您可以创建具有相同 、 和 值的两行，但比较 的值不会反映这是相同的颜色。redgreenblueColorId

The ColorId field shown in Figure 6-1 is not only redundant, but actually creates an opening for bugs. You could create two rows with the same values of red, green, and blue, but comparing the values of ColorId would not reflect that this is the same color.

图 6-1。冗余ColorId字段，使两行具有相同的值成为可能

class Person
{
    private int    _id;
    private string _firstName;
    private string _lastName;
    private string _landlinePhone;
    private string _mobilePhone;
    private string _email;
    private int    _heightMetric;
    private string _countryCode;

    public Person(...) {...}
}

static void Main(string[] args)
{
    var dave = new Person(
        id: 30217,
        firstName: "Dave",
        lastName: "Ancelovici",
        landlinePhone: "023745001",
        mobilePhone: "0873712503",
        email: "dave@learning-ddd.com",
        heightMetric: 180,
        countryCode: "BG");
}

class Person
{
    private int    _id;
    private string _firstName;
    private string _lastName;
    private string _landlinePhone;
    private string _mobilePhone;
    private string _email;
    private int    _heightMetric;
    private string _countryCode;

    public Person(...) {...}
}

static void Main(string[] args)
{
    var dave = new Person(
        id: 30217,
        firstName: "Dave",
        lastName: "Ancelovici",
        landlinePhone: "023745001",
        mobilePhone: "0873712503",
        email: "dave@learning-ddd.com",
        heightMetric: 180,
        countryCode: "BG");
}

class Person {
    private PersonId     _id;
    private Name         _name;
    private PhoneNumber  _landline;
    private PhoneNumber  _mobile;
    private EmailAddress _email;
    private Height       _height;
    private CountryCode  _country;

    public Person(...) { ... }
}

static void Main(string[] args)
{
    var dave = new Person(
        id:       new PersonId(30217),
        name:     new Name("Dave", "Ancelovici"),
        landline: PhoneNumber.Parse("023745001"),
        mobile:   PhoneNumber.Parse("0873712503"),
        email:    Email.Parse("dave@learning-ddd.com"),
        height:   Height.FromMetric(180),
        country:  CountryCode.Parse("BG"));
}

class Person {
    private PersonId     _id;
    private Name         _name;
    private PhoneNumber  _landline;
    private PhoneNumber  _mobile;
    private EmailAddress _email;
    private Height       _height;
    private CountryCode  _country;

    public Person(...) { ... }
}

static void Main(string[] args)
{
    var dave = new Person(
        id:       new PersonId(30217),
        name:     new Name("Dave", "Ancelovici"),
        landline: PhoneNumber.Parse("023745001"),
        mobile:   PhoneNumber.Parse("0873712503"),
        email:    Email.Parse("dave@learning-ddd.com"),
        height:   Height.FromMetric(180),
        country:  CountryCode.Parse("BG"));
}

var heightMetric = Height.Metric(180);
var heightImperial = Height.Imperial(5, 3);

var string1 = heightMetric.ToString();              // "180cm"
var string2 = heightImperial.ToString();            // "5 feet 3 inches"
var string3 = heightMetric.ToImperial().ToString(); // "5 feet 11 inches"

var firstIsHigher = heightMetric > heightImperial; // true

var heightMetric = Height.Metric(180);
var heightImperial = Height.Imperial(5, 3);

var string1 = heightMetric.ToString();              // "180cm"
var string2 = heightImperial.ToString();            // "5 feet 3 inches"
var string3 = heightMetric.ToImperial().ToString(); // "5 feet 11 inches"

var firstIsHigher = heightMetric > heightImperial; // true

var phone = PhoneNumber.Parse("+359877123503");
var country = phone.Country;                        // "BG"
var phoneType = phone.PhoneType;                    // "MOBILE"
var isValid = PhoneNumber.IsValid("+972120266680"); // false

var phone = PhoneNumber.Parse("+359877123503");
var country = phone.Country;                        // "BG"
var phoneType = phone.PhoneType;                    // "MOBILE"
var isValid = PhoneNumber.IsValid("+972120266680"); // false

var red = Color.FromRGB(255, 0, 0);
var green = Color.Green;
var yellow = red.MixWith(green);
var yellowString = yellow.ToString();                // "#FFFF00"

var red = Color.FromRGB(255, 0, 0);
var green = Color.Green;
var yellow = red.MixWith(green);
var yellowString = yellow.ToString();                // "#FFFF00"

public class Color
{
    public readonly byte Red;
    public readonly byte Green;
    public readonly byte Blue;

    public Color(byte r, byte g, byte b)
    {
        this.Red = r;
        this.Green = g;
        this.Blue = b;
    }

    public Color MixWith(Color other)
    {
        return new Color(
            r: (byte) Math.Min(this.Red + other.Red, 255),
            g: (byte) Math.Min(this.Green + other.Green, 255),
            b: (byte) Math.Min(this.Blue + other.Blue, 255)
        );
    }

    ...
}

public class Color
{
    public readonly byte Red;
    public readonly byte Green;
    public readonly byte Blue;

    public Color(byte r, byte g, byte b)
    {
        this.Red = r;
        this.Green = g;
        this.Blue = b;
    }

    public Color MixWith(Color other)
    {
        return new Color(
            r: (byte) Math.Min(this.Red + other.Red, 255),
            g: (byte) Math.Min(this.Green + other.Green, 255),
            b: (byte) Math.Min(this.Blue + other.Blue, 255)
        );
    }

    ...
}

public class Color
{
    ...

    public override bool Equals(object obj)
    {
        var other = obj as Color;
        return other != null &&
            this.Red == other.Red &&
            this.Green == other.Green &&
            this.Blue == other.Blue;
    }

    public static bool operator == (Color lhs, Color rhs)
    {
        if (Object.ReferenceEquals(lhs, null)) {
            return Object.ReferenceEquals(rhs, null);
        }
        return lhs.Equals(rhs);
    }

    public static bool operator != (Color lhs, Color rhs)
    {
        return !(lhs == rhs);
    }

    public override int GetHashCode()
    {
        return ToString().GetHashCode();
    }
    
    ...
}

public class Color
{
    ...

    public override bool Equals(object obj)
    {
        var other = obj as Color;
        return other != null &&
            this.Red == other.Red &&
            this.Green == other.Green &&
            this.Blue == other.Blue;
    }

    public static bool operator == (Color lhs, Color rhs)
    {
        if (Object.ReferenceEquals(lhs, null)) {
            return Object.ReferenceEquals(rhs, null);
        }
        return lhs.Equals(rhs);
    }

    public static bool operator != (Color lhs, Color rhs)
    {
        return !(lhs == rhs);
    }

    public override int GetHashCode()
    {
        return ToString().GetHashCode();
    }
    
    ...
}

实体

Entities

实体是值对象的对立面。它需要一个明确的标识字段来区分实体的不同实例。实体的一个简单例子是人。考虑以下课程：

An entity is the opposite of a value object. It requires an explicit identification field to distinguish between the different instances of the entity. A trivial example of an entity is a person. Consider the following class:

class Person
{
    public Name Name { get; set; }
    
    public Person(Name name)
    {
        this.Name = name;
    }
}

class Person
{
    public Name Name { get; set; }
    
    public Person(Name name)
    {
        this.Name = name;
    }
}

该类仅包含一个字段：（name一个值对象）。然而，这种设计并不是最理想的，因为不同的人可以同名并且可以有完全相同的名字。当然，这并不能使他们成为同一个人。因此，需要一个识别字段来正确识别人：

The class contains only one field: name (a value object). This design, however, is suboptimal because different people can be namesakes and can have exactly the same names. That, of course, doesn’t make them the same person. Hence, an identification field is needed to properly identify people:

class Person
{
    public readonly PersonId Id;
    public Name Name { get; set; }
    
    public Person(PersonId id, Name name)
    {
        this.Id = id;
        this.Name = name;
    }
}

class Person
{
    public readonly PersonId Id;
    public Name Name { get; set; }
    
    public Person(PersonId id, Name name)
    {
        this.Id = id;
        this.Name = name;
    }
}

在前面的代码中，我们引入了标识字段 Id的类型PersonId。PersonId是一个值对象，它可以使用适合业务领域需要的任何底层数据类型。例如，Id可以是 GUID、数字、字符串或特定于域的值（如社会保险号）。

In the preceding code, we introduced the identification field Id of type PersonId. PersonId is a value object, and it can use any underlying data types that fit the business domain’s needs. For example, the Id can be a GUID, a number, a string, or a domain-specific value such as a Social Security number.

标识字段的核心要求是它对于实体的每个实例都应该是唯一的：对于每个人，在我们的例子中（图 6-2）。此外，除了非常罕见的例外，实体标识字段的值在实体的整个生命周期中应该保持不变。这将我们带到值对象和实体之间的第二个概念差异。

The central requirement for the identification field is that it should be unique for each instance of the entity: for each person, in our case (Figure 6-2). Furthermore, except for very rare exceptions, the value of an entity’s identification field should remain immutable throughout the entity’s lifecycle. This brings us to the second conceptual difference between value objects and entities.

图 6-2。引入显式标识字段，允许区分对象的实例，即使所有其他字段的值都相同

与值对象相反，实体不是不可变的，而是会发生变化的。实体和值对象之间的另一个区别是值对象描述实体的属性。在本章的前面，您看到了一个实体示例Person，它有两个值对象来描述每个实例：PersonId和Name。

Contrary to value objects, entities are not immutable and are expected to change. Another difference between entities and value objects is that value objects describe an entity’s properties. Earlier in the chapter, you saw an example of the entity Person and it had two value objects describing each instance: PersonId and Name.

实体是任何业务领域的基本构建块。也就是说，您可能已经注意到，在本章的前面，我没有将“实体”包括在域模型构建块的列表中。那不是错误。省略“实体”的原因是因为我们不是独立地实现实体，而是仅在聚合模式的上下文中实现。

Entities are an essential building block of any business domain. That said, you may have noticed that earlier in the chapter I didn’t include “entity” in the list of the domain model’s building blocks. That’s not a mistake. The reason “entity” was omitted is because we don’t implement entities independently, but only in the context of the aggregate pattern.

骨料

Aggregates

聚合是一个实体：它需要一个明确的标识字段及其状态预计会在实例的生命周期中发生变化。然而，它不仅仅是一个实体。该模式的目标是保护其数据的一致性。由于聚合的数据是可变的，因此模式必须解决一些影响和挑战，以始终保持其状态一致。

An aggregate is an entity: it requires an explicit identification field and its state is expected to change during an instance’s lifecycle. However, it is much more than just an entity. The goal of the pattern is to protect the consistency of its data. Since an aggregate’s data is mutable, there are implications and challenges that the pattern has to address to keep its state consistent at all times.

public class Ticket
{
    ...

    public void AddMessage(UserId from, string body)
    {
        var message = new Message(from, body);
        _messages.Append(message);
    }

    ...
}

public class Ticket
{
    ...

    public void AddMessage(UserId from, string body)
    {
        var message = new Message(from, body);
        _messages.Append(message);
    }

    ...
}

public class Ticket
{
    ...
 
    public void Execute(AddMessage cmd)
    {
        var message = new Message(cmd.from, cmd.body);
        _messages.Append(message);
    }

    ...
}

public class Ticket
{
    ...
 
    public void Execute(AddMessage cmd)
    {
        var message = new Message(cmd.from, cmd.body);
        _messages.Append(message);
    }

    ...
}

01  public ExecutionResult Escalate(TicketId id, EscalationReason reason)
02  {
03      try
04      {
05          var ticket = _ticketRepository.Load(id);
06          var cmd = new Escalate(reason);
07          ticket.Execute(cmd);
08          _ticketRepository.Save(ticket);
09          return ExecutionResult.Success();
10      }
11      catch (ConcurrencyException ex)
12      {
13          return ExecutionResult.Error(ex);
14      }
15  }

01  public ExecutionResult Escalate(TicketId id, EscalationReason reason)
02  {
03      try
04      {
05          var ticket = _ticketRepository.Load(id);
06          var cmd = new Escalate(reason);
07          ticket.Execute(cmd);
08          _ticketRepository.Save(ticket);
09          return ExecutionResult.Success();
10      }
11      catch (ConcurrencyException ex)
12      {
13          return ExecutionResult.Error(ex);
14      }
15  }

class Ticket
{
    TicketId _id;
    int      _version;

    ...
}

class Ticket
{
    TicketId _id;
    int      _version;

    ...
}

01  UPDATE tickets
02  SET ticket_status = @new_status,
03  agg_version = agg_version + 1
04  WHERE ticket_id=@id and agg_version=@expected_version;

01  UPDATE tickets
02  SET ticket_status = @new_status,
03  agg_version = agg_version + 1
04  WHERE ticket_id=@id and agg_version=@expected_version;

实体的层次结构

Hierarchy of entities

正如我们在本章前面所讨论的，我们不使用实体作为一个独立的模式，仅作为聚合的一部分。让我们看看实体和聚合之间的根本区别，以及为什么实体是聚合的构建块而不是总体域模型的构建块。

As we discussed earlier in the chapter, we don’t use entities as an independent pattern, only as part of an aggregate. Let’s see the fundamental difference between entities and aggregates, and why entities are a building block of an aggregate rather than of the overarching domain model.

在某些业务场景中，多个对象应该共享一个事务边界；例如，当两者可以同时修改或一个对象的业务规则取决于另一个对象的状态时。

There are business scenarios in which multiple objects should share a transactional boundary; for example, when both can be modified simultaneously or the business rules of one object depend on the state of another object.

DDD 规定系统的设计应由其业务领域驱动。聚合也不例外。为了支持必须在一个原子事务中应用的多个对象的更改，聚合模式类似于实体的层次结构，所有共享事务一致性，如图 6-3所示。

DDD prescribes that a system’s design should be driven by its business domain. Aggregates are no exception. To support changes to multiple objects that have to be applied in one atomic transaction, the aggregate pattern resembles a hierarchy of entities, all sharing transactional consistency, as shown in Figure 6-3.

图 6-3。聚合为实体的层次结构

层次结构包含实体和值对象，如果它们受域的业务逻辑约束，则它们都属于同一个聚合。

The hierarchy contains both entities and value objects, and all of them belong to the same aggregate if they are bound by the domain’s business logic.

这就是该模式被命名为“聚合”的原因：它聚合了属于同一事务边界的业务实体和值对象。

That’s why the pattern is named “aggregate”: it aggregates business entities and value objects that belong to the same transaction boundary.

以下代码示例演示了跨越属于聚合边界的多个实体的业务规则——“如果代理未在响应时间限制的 50% 内打开升级工单，它会自动重新分配给不同的代理”：

The following code sample demonstrates a business rule that spans multiple entities belonging to the aggregate’s boundary—“If an agent didn’t open an escalated ticket within 50% of the response time limit, it is automatically reassigned to a different agent”:

01  public class Ticket
02  {
03      ...
04      List<Message> _messages;
05      ...
06 
07      public void Execute(EvaluateAutomaticActions cmd)
08      {
09          if (this.IsEscalated && this.RemainingTimePercentage < 0.5 &&
10              GetUnreadMessagesCount(for: AssignedAgent) > 0)
11          {
12              _agent = AssignNewAgent();
13          }
14      }
15 
16      public int GetUnreadMessagesCount(UserId id)
17      {
18          return _messages.Where(x => x.To == id && !x.WasRead).Count();
19      }
20
21      ...
22  }

01  public class Ticket
02  {
03      ...
04      List<Message> _messages;
05      ...
06 
07      public void Execute(EvaluateAutomaticActions cmd)
08      {
09          if (this.IsEscalated && this.RemainingTimePercentage < 0.5 &&
10              GetUnreadMessagesCount(for: AssignedAgent) > 0)
11          {
12              _agent = AssignNewAgent();
13          }
14      }
15 
16      public int GetUnreadMessagesCount(UserId id)
17      {
18          return _messages.Where(x => x.To == id && !x.WasRead).Count();
19      }
20
21      ...
22  }

该方法检查工单的值以查看它是否升级以及剩余处理时间是否小于定义的阈值 50%（第 9 行）。此外，它还会检查当前代理尚未读取的消息（第 10 行）。如果满足所有条件，则请求将票重新分配给不同的代理。

The method checks the ticket’s values to see whether it is escalated and whether the remaining processing time is less than the defined threshold of 50% (line 9). Furthermore, it checks for messages that were not yet read by the current agent (line 10). If all conditions are met, the ticket is requested to be reassigned to a different agent.

聚合确保所有条件都根据高度一致的数据进行检查，并且通过确保对聚合数据的所有更改都作为一个原子事务执行，在检查完成后它不会更改。

The aggregate ensures that all the conditions are checked against strongly consistent data, and it won’t change after the checks are completed by ensuring that all changes to the aggregate’s data are performed as one atomic transaction.

引用其他聚合

Referencing other aggregates

由于聚合包含的所有对象共享相同的如果聚合增长太大，可能会出现事务边界、性能和可伸缩性问题。

Since all objects contained by an aggregate share the same transactional boundary, performance and scalability issues may arise if an aggregate grows too large.

数据的一致性可以成为设计聚合边界的方便指导原则。只有聚合的业务逻辑要求高度一致的信息才应该是聚合的一部分。所有最终一致的信息都应该位于聚合边界之外；例如，作为另一个聚合的一部分，如图6-4所示。

The consistency of the data can be a convenient guiding principle for designing an aggregate’s boundaries. Only the information that is required by the aggregate’s business logic to be strongly consistent should be a part of the aggregate. All information that can be eventually consistent should reside outside of the aggregate’s boundary; for example, as a part of another aggregate, as shown in Figure 6-4.

图 6-4。聚合为一致性边界

经验法则是使聚合尽可能小，并且仅包含聚合的业务逻辑要求处于高度一致状态的对象：

The rule of thumb is to keep the aggregates as small as possible and include only objects that are required to be in a strongly consistent state by the aggregate’s business logic:

public class Ticket
{
    private UserId          _customer;
    private List<ProductId> _products;
    private UserId          _assignedAgent;
    private List<Message>   _messages;

    ...
}

public class Ticket
{
    private UserId          _customer;
    private List<ProductId> _products;
    private UserId          _assignedAgent;
    private List<Message>   _messages;

    ...
}

在前面的示例中，Ticket聚合引用了属于聚合边界的消息集合。另一方面，客户、与工单相关的产品集合以及分配的代理不属于聚合，因此由其 ID 引用。

In the preceding example, the Ticket aggregate references a collection of messages, which belong to the aggregate’s boundary. On the other hand, the customer, the collection of products that are relevant to the ticket, and the assigned agent do not belong to the aggregate and therefore are referenced by its ID.

通过 ID 引用外部聚合背后的原因是为了具体化这些对象不属于聚合的边界，并确保每个聚合都有自己的事务边界。

The reasoning behind referencing external aggregates by ID is to reify that these objects do not belong to the aggregate’s boundary, and to ensure that each aggregate has its own transactional boundary.

要确定一个实体是否属于聚合，请检查聚合是否包含可能导致无效系统状态的业务逻辑（如果它处理最终一致的数据）。让我们回到前面的示例，如果当前代理未在响应时间限制的 50% 内阅读新消息，则重新分配工单。如果有关已读/未读消息的信息最终是一致的怎么办？换句话说，在一定延迟之后接收阅读确认是合理的。在这种情况下，可以安全地预期相当多的票证会被不必要地重新分配。那当然会破坏系统的状态。因此，消息中的数据属于聚合的边界。

To decide whether an entity belongs to an aggregate or not, examine whether the aggregate contains business logic that can lead to an invalid system state if it will work on eventually consistent data. Let’s go back to the previous example of reassigning the ticket if the current agent didn’t read the new messages within 50% of the response time limit. What if the information about read/unread messages would be eventually consistent? In other words, it would be reasonable to receive reading acknowledgment after a certain delay. In that case, it’s safe to expect a considerable number of tickets to be unnecessarily reassigned. That, of course, would corrupt the system’s state. Therefore, the data in the messages belongs to the aggregate’s boundary.

聚合根

The aggregate root

我们之前看到聚合的状态只能被修改通过执行它的命令之一。由于聚合表示实体的层次结构，因此只有其中一个实体应该被指定为聚合的公共接口——聚合根，如图6-5所示。

We saw earlier that an aggregate’s state can only be modified by executing one of its commands. Since an aggregate represents a hierarchy of entities, only one of them should be designated as the aggregate’s public interface—the aggregate root, as shown in Figure 6-5.

图 6-5。聚合根

考虑以下聚合摘录Ticket：

Consider the following excerpt of the Ticket aggregate:

public class Ticket
{
   ...
   List<Message> _messages;
   ...

   public void Execute(AcknowledgeMessage cmd)
   {
      var message = _messages.Where(x => x.Id == cmd.id).First();
      message.WasRead = true;
   }
   ...
}

public class Ticket
{
   ...
   List<Message> _messages;
   ...

   public void Execute(AcknowledgeMessage cmd)
   {
      var message = _messages.Where(x => x.Id == cmd.id).First();
      message.WasRead = true;
   }
   ...
}

在此示例中，聚合公开了一个允许将特定消息标记为已读的命令。尽管该操作修改了实体的实例Message，但它只能通过其聚合根访问：Ticket。

In this example, the aggregate exposes a command that allows marking a specific message as read. Although the operation modifies an instance of the Message entity, it is accessible only through its aggregate root: Ticket.

除了聚合根的公共接口外，外部世界还可以通过另一种机制与聚合进行通信：领域事件。

In addition to the aggregate root’s public interface, there is another mechanism through which the outer world can communicate with aggregates: domain events.

领域事件

Domain events

领域事件是描述重要事件的消息这已经发生在业务领域。例如：

A domain event is a message describing a significant event that has occurred in the business domain. For example:

• 已分配工单

• Ticket assigned

• 工单升级

• Ticket escalated

• 收到消息

• Message received

由于领域事件描述的是已经发生的事情，因此它们的名称应该用过去时表示。

Since domain events describe something that has already happened, their names should be formulated in the past tense.

领域事件的目标是描述业务领域中发生的事情，并提供与事件相关的所有必要数据。例如，以下域事件表明特定工单已升级、升级时间和原因：

The goal of a domain event is to describe what has happened in the business domain and provide all the necessary data related to the event. For example, the following domain event communicates that the specific ticket was escalated, at what time, and for what reason:

{
    "ticket-id": "c9d286ff-3bca-4f57-94d4-4d4e490867d1",
    "event-id": 146,
    "event-type": "ticket-escalated",
    "escalation-reason": "missed-sla",
    "escalation-time": 1628970815
}

{
    "ticket-id": "c9d286ff-3bca-4f57-94d4-4d4e490867d1",
    "event-id": 146,
    "event-type": "ticket-escalated",
    "escalation-reason": "missed-sla",
    "escalation-time": 1628970815
}

与软件工程中的几乎所有事物一样，命名很重要。确保领域事件的名称简洁准确地反映了业务领域中发生的事情。

As with almost everything in software engineering, naming is important. Make sure the names of the domain events succinctly reflect exactly what has happened in the business domain.

领域事件是聚合公共接口的一部分。聚合发布其领域事件。其他进程、聚合甚至外部系统都可以订阅并执行自己的逻辑以响应领域事件，如图6-6所示。

Domain events are part of an aggregate’s public interface. An aggregate publishes its domain events. Other processes, aggregates, or even external systems can subscribe to and execute their own logic in response to the domain events, as shown in Figure 6-6.

图 6-6。领域事件发布流程

在聚合的以下摘录中Ticket，一个新的领域事件被实例化（第 12 行）并附加到票证领域事件的集合中（第 13 行）：

In the following excerpt from the Ticket aggregate, a new domain event is instantiated (line 12) and appended to the collection of the ticket’s domain events (line 13):

01  public class Ticket
02  {
03      ...
04      private List<DomainEvent> _domainEvents;
05      ...
06 
07      public void Execute(RequestEscalation cmd)
08      {
09          if (!this.IsEscalated && this.RemainingTimePercentage <= 0)
10          {
11              this.IsEscalated = true;
12              var escalatedEvent = new TicketEscalated(_id, cmd.Reason);
13              _domainEvents.Append(escalatedEvent);
14          }
15      }
16
17      ...
18  }

01  public class Ticket
02  {
03      ...
04      private List<DomainEvent> _domainEvents;
05      ...
06 
07      public void Execute(RequestEscalation cmd)
08      {
09          if (!this.IsEscalated && this.RemainingTimePercentage <= 0)
10          {
11              this.IsEscalated = true;
12              var escalatedEvent = new TicketEscalated(_id, cmd.Reason);
13              _domainEvents.Append(escalatedEvent);
14          }
15      }
16
17      ...
18  }

在第 9 章中，我们将讨论如何将领域事件可靠地发布给感兴趣的订阅者。

In Chapter 9, we will discuss how domain events can be reliably published to interested subscribers.

领域服务

Domain services

迟早，您可能会遇到业务逻辑不属于任何聚合或值对象，或者似乎与多个聚合相关。在这种情况下，领域驱动设计建议将逻辑实现为领域服务。

Sooner or later, you may encounter business logic that either doesn’t belong to any aggregate or value object, or that seems to be relevant to multiple aggregates. In such cases, domain-driven design proposes to implement the logic as a domain service.

域服务是实现业务逻辑的无状态对象。在绝大多数情况下，此类逻辑会协调对系统各个组件的调用以执行某些计算或分析。

A domain service is a stateless object that implements the business logic. In the vast majority of cases, such logic orchestrates calls to various components of the system to perform some calculation or analysis.

让我们回到工单聚合的例子。回想一下，指定的代理向客户提出解决方案的时间有限。时间范围不仅取决于工单的数据（其优先级和升级状态），还取决于代理部门关于每个优先级的 SLA 的政策和代理的工作时间表（轮班）——我们不能期望代理在期间做出响应下班时间。

Let’s go back to the example of the ticket aggregate. Recall that the assigned agent has a limited time frame in which to propose a solution to the customer. The time frame depends not only on the ticket’s data (its priority and escalation status), but also on the agent’s department policy regarding the SLAs for each priority and the agent’s work schedule (shifts)—we can’t expect the agent to respond during off-hours.

响应时间范围计算逻辑需要来自多个来源的信息：工单、指定代理的部门和工作时间表。这使得它成为作为域服务实现的理想候选者：

The response time frame calculation logic requires information from multiple sources: the ticket, the assigned agent’s department, and the work schedule. That makes it an ideal candidate to be implemented as a domain service:

public class ResponseTimeFrameCalculationService
{
    ...

    public ResponseTimeframe CalculateAgentResponseDeadline(UserId agentId,
        Priority priority, bool escalated, DateTime startTime)
    {
        var policy = _departmentRepository.GetDepartmentPolicy(agentId);
        var maxProcTime = policy.GetMaxResponseTimeFor(priority);

        if (escalated) {
            maxProcTime = maxProcTime * policy.EscalationFactor;
        }

        var shifts = _departmentRepository.GetUpcomingShifts(agentId,
            startTime, startTime.Add(policy.MaxAgentResponseTime));
        
        return CalculateTargetTime(maxProcTime, shifts);
    }

    ...
}

public class ResponseTimeFrameCalculationService
{
    ...

    public ResponseTimeframe CalculateAgentResponseDeadline(UserId agentId,
        Priority priority, bool escalated, DateTime startTime)
    {
        var policy = _departmentRepository.GetDepartmentPolicy(agentId);
        var maxProcTime = policy.GetMaxResponseTimeFor(priority);

        if (escalated) {
            maxProcTime = maxProcTime * policy.EscalationFactor;
        }

        var shifts = _departmentRepository.GetUpcomingShifts(agentId,
            startTime, startTime.Add(policy.MaxAgentResponseTime));
        
        return CalculateTargetTime(maxProcTime, shifts);
    }

    ...
}

领域服务使协调多个聚合的工作变得容易。但是，始终牢记聚合模式的局限性很重要，即在一个数据库事务中只能修改聚合的一个实例。领域服务并不是绕过这个限制的漏洞。每笔交易一个实例的规则仍然适用。相反，域服务有助于实现需要读取多个聚合数据的计算逻辑。

Domain services make it easy to coordinate the work of multiple aggregates. However, it is important to always keep in mind the aggregate pattern’s limitation of modifying only one instance of an aggregate in one database transaction. Domain services are not a loophole around this limitation. The rule of one instance per transaction still holds true. Instead, domain services lend themselves to implementing calculation logic that requires reading the data of multiple aggregates.

同样重要的是要指出，域服务与微服务、面向服务的体系结构或软件工程中服务一词的几乎任何其他用法都无关。它只是一个用于承载业务逻辑的无状态对象。

It is also important to point out that domain services have nothing to do with microservices, service-oriented architecture, or almost any other use of the word service in software engineering. It is just a stateless object used to host business logic.